Release 10.1A: OpenEdge Development:
ADM and SmartObjects

Super procedures

All support code for an object type, other than the code in its primary include file, is in a separately compiled super procedure built as a structured .p file. For example, the super procedure for SmartDataViewers is viewer.p.

During startup, the .p file is run and established as a super procedure for each of its SmartObjects running in that session. Its routines use TARGET-PROCEDURE to get the procedure handle of the appropriate SmartObject and can then get property values from that procedure to get handles or other data needed to act on behalf of the SmartObject. These SmartObjects can run any internal procedure or function implemented in one of the object’s super procedures as if it were implemented in the SmartObject itself. This allows these separately compiled procedure objects to do the following:

Support standard behavior for all SmartObjects of a given type running in a Progress session.
Enable the customization or overriding of these procedures and functions in individual SmartObjects.

For an overview of super procedures, see OpenEdge Development: Progress 4GL Handbook . For descriptions of super procedures and TARGET-PROCEDURE, see OpenEdge Development: Progress 4GL Reference .

Figure 5–1 illustrates this relationship.

Figure 5–1: Super procedures and master interactions

The smart.p code uses TARGET-PROCEDURE to reference the two masters. For master1.w, the xyz procedure in the smart.p super procedure is run because master1.w does not have its own xyz procedure. For master2.w, its own xyz procedure is run and then, because it executes RUN SUPER, the xyz procedure in smart.p also is run.

As this example illustrates, using super procedures to provide most of the support code for a SmartObject provides these advantages:

Encapsulation of routines into a super procedure where they are accessible from all SmartObjects associated with that super procedure.
The ability to use the same procedure or function name in multiple layers when defining the behavior for a particular SmartObject.

Each super procedure must define a getpropname function for each object property that can be retrieved from objects of that type and a setpropname function for each settable property. For more information on these properties, see the "Get and set functions for object properties" section.

Super procedures are not SmartObjects in themselves and are not directly seen or manipulated in the AppBuilder during application assembly. They do not have SmartLinks, nor do they have properties of their own.

The super procedures for SmartObjects are designed to be shared and stateless. This means a given super procedure such as viewer.p is run only once in a session. No matter how many SmartDataViewers there are, each SmartDataViewer designates the same instance of viewer.p as its super procedure. This means whenever a routine is invoked in viewer.p as a super procedure, it queries whatever properties of its TARGET-PROCEDURE are needed for it to act. The next routine invoked in viewer.p is not assumed to come from the same TARGET-PROCEDURE.